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MIME media types for ISUP and QSIG Objects 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2001). All Rights Reserved. 
Abstract 


This document describes MIME types for application/ISUP and 
application/QSIG objects for use in SIP applications, according to 
the rules defined in RFC 2048. These types can be used to identify 
ISUP and QSIG objects within a SIP message such as INVITE or INFO, as 
might be implemented when using SIP in an environment where part of 
the call involves interworking to the PSTN. 


1. Introduction 


ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is 
a signaling protocol used between telephony switches. There are 
configurations in which ISUP-encoded signaling information needs to 
be transported between SIP entities as part of the payload of SIP 
messages, where the preservation of ISUP data is necessary for the 
proper operation of PSTN features. 
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QSIG is the analogous signaling protocol used between private branch 
exchanges to support calls within private telephony networks. There 
is a similar need to transport QSIG-encoded signaling information 
between SIP entities in some environments. 


This document is specific to this usage and would not apply to the 
transportation of ISUP or QSIG messages in other applications. These 
media types are intended for ISUP or QSIG application information 
that is used within the context of a SIP session, and not as general 
purpose transport of SCN signaling. 


The definition of media types for ISUP and QSIG application 
information does not address fully how the non-SIP and SIP entities 
exchanging messages determine or negotiate compatibility. It is 
assumed that this is addressed by alternative means such as the 
configuration of the interworking functions. 


This is intended to be an IETF approved MIME type, and to be defined 
through an RFC. NOTE: usage of Q.SIG within SIP is neither endorsed 
nor recommended as a result of this MIME registration. 


3. Proposed new media types 


ISUP and QSIG messages are composed of arbitrary binary data that is 
transparent to SIP processing. The best way to encode these is to use 
binary encoding. This is in conformance with the restrictions imposed 
on the use of binary data for MIME (RFC 2045 [3]). It should be noted 
that the rules mentioned in the RFC 2045 apply to Internet mail 
messages and not to SIP messages. Binary has been preferred over 
Base64 encoding because the latter would only result in adding bulk 
to the encoded messages and possibly be more costly in terms of 
processing power. 


3.1 ISUP Media Type 
This media type is defined by the following information: 


Media type name: application 

Media subtype name: ISUP 

Required parameters: version 

Optional parameters: base 

Encoding scheme: binary 

Security considerations: See section 5. 


The ISUP message is encapsulated beginning with the Message Type Code 
(i.e., omitting Routing Label and Circuit ID Code). 
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The use of the ’version’ parameter allows network administrators to 
identify specific versions of ISUP that will be exchanged on a 
bilateral basis. This enables a particular client such as a 
SoftSwitch/Media Gateway Controller to recognize and parse the 
message correctly, or (possibly) to reject the message if the 
specified ISUP version is not supported. This specification places no 
constraints on the values that may be used in /’/version’; these are 
left to the discretion of the network administrator. 


This ’version’ could, for example, be used to identify a network- 
specific implementation of ISUP, e.g., X-NetxProprietaryISUPv3, or to 
identify a well-known standard version of ISUP, e.g., itu-t or ansi. 


A ‘base’ parameter can optionally be included in some cases (e.g., if 
the receiver may not recognize the /’/version’ string) to specify that 
the encapsulated ISUP can also be processed using the identified 
‘base’ specification. Table 1 provides a list of ’base’ values 
supported by the ’application/ISUP’ media type, including whether or 
not the forward compatibility mechanism defined in ITU-T 1992 ISUP is 


supported. 
Table 1: ISUP ’base’ values 
base protocol compatibility 
itu-t88 ITU-T Q.761-4 (1988) no 
itu-t92+ ITU-T Q.761-4 (1992) yes 
ansi88 ANSI T1.113-1988 no 
ansi00 ANSI T1.113-2000 yes 
etsil21 ETS 300 121 no 
etsi356 ES 300 356 yes 
gr317 BELLCORE GR-317 no 
ttc87 JT-Q761-4 (1987-1992) no 
EbeCI3S+ JT-Q761-4 (1993-) yes 


The Content-—Disposition header [5] may be included to describe how 
the encapsulated ISUP is to be processed, and in particular what the 
handling should be if the received Content-Type is not recognized. 
The default disposition-type for an ISUP message body is "Signal". 
This type indicates that the body part contains signaling information 
associated with the session, but does not describe the session. 


Supplementing the description of the Content-—Disposition header in 
[5], as well as any characterization of the Content-—Disposition 
header in the SIP standard, is the following BNF describing 
disposition-types and disposition-params that may be used in the 
header of ISUP and QSIG MIME bodies. 
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Content-—Disposition = "Content-Disposition" ":" 
disposition-type *( ";" disposition-param ) 
disposition-type = "signal" | disp-extension-token 
disposition-param = "handling" "=" 
( "optional" | "required" | other-handling ) 
generic—param 
other-handling = token 
disp-extension-token = token 


A full definition of the use of the "handling" parameter is given in 
the IANA Considerations section below. The following is how a 
typical header would look (’base’ may be omitted): 


Content-Type: application/ISUP; version=nxv3; base=etsil21 
Content-—Disposition: signal; handling=optional 


3.2 QSIG Media Type 


The application/QSIG media type is defined by the following 
information: 


Media type name: application 

Media subtype name: QSIG 

Required parameters: none 

Optional parameters: version 

Encoding scheme: binary 

Security considerations: See section 5. 


The use of the ’version’ parameter allows identification of different 
QSIG variants. This enables the terminating Connection Server to 
recognize and parse the message correctly, or (possibly) to reject 
the message if the particular QSIG variant is not supported. 


Table 2 is a list of protocol versions supported by the 
‘application/QSIG’ media type. 


Table 2: QSIG versions 
version protocol 


iso ISO/IEC 11572 (Basic Call) and 
ISO/IEC 11582 (Generic Functional Protocol) 
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The following is how a typical header would look (Content-—Disposition 
not included in this instance): 


Content-Type: application/QSIG; version=iso 


The default Content-Disposition disposition-type is "Signal" as in an 
ISUP body part. The "handling" parameter described above can also be 
used for QSIG bodies. 


4. Illustrative examples 
4.1 ISUP 


SIP message format requires a Request line followed by Header lines 
followed by a CRLF separator followed by the message body. To 
illustrate the use of the ’application/ISUP’ media type, below is an 
INVITE message which has the originating SDP information and an 
encapsulated ISUP IAM. 


Note that the two payloads are demarcated by the boundary parameter 
(specified in RFC 2046 [4]) which in the example has the value 
"unique-boundary-1". This is part of the specification of MIME 
multipart and is not related to the 


INVITE sip:13039263142@Den1.level3.com SIP/2.0 

Via: SIP/2.0/UDP den3.level3.com 

From: sip:13034513355@den3.level3.com 

To: sip:13039263142@Den1.level3.com 

Call-ID: DEN1231999021712095500999@Den1.1level3.com 

CSeq: 8348 INVITE 

Contact: <sip: jpeterson@level3.com> 

Content-Length: 436 

Content-Type: multipart/mixed; boundary=unique-boundary-1 
MIME-Version: 1.0 


--unique-boundary-1 
Content-Type: application/SDP; charset=ISO-10646 


v=0 

o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4 
s=SDP seminar 

c=IN IP4 MG122.level3.com 

t= 2873397496 2873404696 

m=audio 9092 RTP/AVP 0 3 4 

—-unique-boundary-1 

Content-Type: application/ISUP; version=nxv3; 
base=etsil21 

Content—Disposition: signal; handling=optional 
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00 03 02 00 07 04 10 00 33 63 21 
06 Od 03 80 90 a2 07 03 10 03 63 
07 03 10 27 80 88 03 00 00 89 8b 
le 06 26 05 Od £5 01 06 10 04 00 


-—-unique-boundary-1-- 


Note: Since binary encoding is used for the ISUP payload, each byte 
is encoded as a byte, and not as a two-character hex representation. 
Hex digits were used in the document because a literal encoding of 


those bytes would 
4.2 QSIG 

To illustrate the 

an INVITE message 


encapsulated QSIG 


Note that the two 
(specified in RFC 


"unique- boundary- 


have been confusing and unreadable. 


use of the ’application/QSIG’ media type, below is 
which has the originating SDP information and an 
SETUP message. 


payloads are demarcated by the boundary parameter 
2046 [4]) which in the example has the value 
1". This is part of the specification of MIME 


multipart and is not related to the ’application/QSIG’ media type. 


INVITE sip:14084955072@scl.nortelnetworks.com SIP/2.0 
Via: SIP/2.0/UDP scl0.nortelnetworks.com 

From: sip:14085655675@sc10.nortelnetworks.com 

To: sip:14084955072@scl.nortelnetworks.com 

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com 
CSeq: 1234 INVITE 

Contact: <sip:14085655675@sc10.nortelnetworks.com> 
Content-Length: 358 

Content-Type: multipart/mixed; boundary=unique-boundary-1 
MIME-Version: 1.0 


-—-unique-boundary-1 
Content-Type: application/SDP; charset=ISO-10646 


v=0 


o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4 
s=SDP seminar 

c=IN IP4 MG141.nortelnetworks.com 

t= 2873397496 2873404696 

m=audio 9092 RTP/AVP 0 3 4 
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--unique-boundary-1 
Content-type:application/QSIG; version=iso 


08 02 55 55 05 04 02 90 90 18 03 al 83 01 
70 Oa 89 31 34 30 38 34 39 35 35 30 37 32 
-—-unique-boundary-1-- 


5. Security considerations 


Information contained in ISUP and QSIG bodies may include sensitive 
customer information, potentially requiring use of encryption. 


Security mechanisms are provided in RFC 2543 (SIP - Session 
Initiation Protocol) and should be used as appropriate for both the 
SIP message and the encapsulated ISUP or QSIG body. 


6. IANA considerations 


This document registers the "application/ISUP" and "application/QSIG" 
MIME media types. 


Registrations for the ’version’ symbols used within the ISUP and QSIG 
MIME types must specify a definitive specification reference, 
identifying a particular issue of the specification, to which the new 
symbol shall refer. Identifying a definite specification reference 
requires a review process; the authors recommend that a subject 
matter expert be designated as described in RFC 2434 [6] under Expert 
Review. 


Note that where a specification is fully peer-to-peer backwards 
compatible with a previous issue (i.e., the compatibility mechanism 
is supported by both), then there is no need for separate symbols to 
be registered. The symbol for the original specification should be 
used to identify backwards-compatible upgrades of that specification 
as well. 


Symbols beginning with the characters ’X-’ are reserved for non- 
standard usage (e.g., cases in which a token other than a string 
representing an issue of an ISUP specification is appropriate for 
characterizing ISUP within an administrative domain). Such non- 
standard version can only be transmitted between administrative 
domains in accordance with a bilateral agreement. These symbols 
should be administered under the Private Use policy described in RFC 
2434. 
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This document registers a new disposition-type for the Content- 
Disposition header, ’signal’, to be used when a MIME body contains 
supplemental signaling information (ISUP and QSIG as MIME bodies 
being examples of this). 


This document also defines a Content Disposition parameter, 
"handling". The handling parameter, handling-parm, describes how the 
UAS should react if it receives a message body whose content type or 
disposition type it does not understand. If the parameter has the 
value "optional", the UAS MUST ignore the message body; if it has the 
value "required", the UAS MUST return 415 (Unsupported Media Type). 
If the handling parameter is missing, the value "required" is to be 
assumed. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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